Sementara tahun lalu atau dua telah melihat sejumlah proposal untuk perpanjangan yang mengusulkan perjanjian untuk Bitcoin, selalu ada kecurigaan di kalangan para ahli bahwa perjanjian mungkin memungkinkan tanpa adanya perpanjangan. Bukti untuk ini datang dalam dua bentuk: repertoar komputasi yang sebelumnya dianggap tidak mungkin berkembang (yang mencapai puncaknya dalam proyek BitVM untuk mengimplementasikan setiap opcode RISC-V), dan serangkaian "hampir-hampir" dimana pengembang Bitcoin telah menemukan cara bahwa perjanjian mungkin telah memungkinkan, jika bukan karena beberapa kejadian sejarah yang gelap dari .
Ethan Heilman, Avihu Levy, Victor Kobolov, dan saya telah mengembangkan sebuah skema yang membuktikan bahwa kecurigaan ini berdasar. Skema kita, Collider, memungkinkan perjanjian di Bitcoin saat ini, dengan asumsi kriptografi yang cukup masuk akal dan biaya sekitar 50 juta dolar per transaksi (ditambah dengan beberapa riset dan pengembangan perangkat keras).
Meskipun biaya yang fantastis untuk menggunakan Collider, pengaturannya sangat murah, dan melakukannya (bersama mekanisme pengeluaran biasa, menggunakan Taproot untuk memisahkan keduanya) mungkin saja menyelamatkan koin Anda jika komputer kuantum muncul tiba-tiba dan meledakkan semuanya.
Tak diragukan lagi banyak pembaca, setelah membaca klaim-klaim ini, akan mengangkat satu alis ke langit. Ketika Anda selesai membaca artikel ini, alis yang lain akan sama tingginya.
Perjanjian
Konteks dari diskusi ini, bagi mereka yang tidak familiar, adalah bahwa Bitcoin memiliki bahasa pemrograman bawaan, yang disebut Bitcoin, yang digunakan untuk mengotorisasi pengeluaran koin. Pada awalnya, Bitcoin mengandung seperangkat lengkap kode operasi aritmatika yang dapat digunakan untuk menerapkan perhitungan sembarang. Tetapi pada musim panas 2010, Satoshi menonaktifkan banyak dari ini dalam pesanan untuk menghentikan serangkaian bug serius. (Kembali ke versi sebelum 2010 dari Bitcoin adalah tujuan dari Proyek Restorasi Hebat; OP_CAT adalah proposal yang kurang ambisius dengan arah yang sama.) Ide kovenan - transaksi yang menggunakan Bitcoin untuk mengontrol jumlah dan tujuan koin mereka - tidak muncul dalam beberapa tahun lagi, dan kesadaran bahwa kode operasi ini sudah cukup untuk menerapkan kovenan baru muncul bahkan lebih lama. Pada saat itu, komunitas sudah terlalu besar dan berhati-hati untuk sekadar "mengaktifkan kembali" kode operasi lama dengan cara yang sama seperti saat mereka dinonaktifkan.
Covenants adalah konstruksi hipotetis yang akan memungkinkan pengguna mengontrol tidak hanya kondisi di mana koin dihabiskan, tetapi juga tujuan mereka. Ini adalah dasar untuk banyak konstruksi yang akan ada di Bitcoin, mulai dari brankas dan dompet terbatas tarif, hingga mekanisme pasar biaya baru seperti kolam pembayaran, hingga konstruksi yang kurang menyenangkan seperti keuangan terdistribusi dan MEV. Jutaan kata telah dihabiskan untuk mendebatkan keinginan akan covenants dan apa yang akan mereka lakukan terhadap sifat Bitcoin.
Dalam artikel ini, saya akan menghindari perdebatan ini, dan hanya berargumen bahwa perjanjian sudah mungkin dilakukan pada Bitcoin; bahwa kita pada akhirnya akan menemukan bagaimana hal-hal itu mungkin dilakukan (tanpa biaya komputasi yang besar atau asumsi kriptografis yang meragukan); dan bahwa perdebatan kita tentang perluasan baru untuk Bitcoin tidak boleh dianggap sebagai garis pemisah antara masa depan Bitcoin tanpa perjanjian atau masa depan Bitcoin dengan perjanjian.
Sejarah
Selama bertahun-tahun, sebuah tradisi berkembang untuk menemukan cara-cara kreatif untuk melakukan hal-hal yang tidak sepele meskipun dengan sumber daya terbatas. Jaringan Lightning adalah salah satu contoh dari hal ini, begitu juga dengan gagasan-gagasan yang kurang dikenal seperti pembayaran probabilitas atau hadiah tabrakan untuk fungsi hash. Kasus-kasus tepi yang tidak terlalu dikenal, seperti bug SIGHASH_SINGLE atau penggunaan pemulihan kunci publik untuk mendapatkan "hash transaksi" dalam interpreter, diperhatikan dan dieksplorasi, tetapi tidak ada yang berhasil menemukan cara untuk membuat mereka berguna. Sementara itu, Bitcoin sendiri berkembang menjadi lebih terdefinisi dengan lebih baik, menutup banyak pintu-pintu ini. Misalnya, Segwit menghilangkan bug SIGHASH_SINGLE dan secara eksplisit memisahkan data program dari data saksi; Taproot menghilangkan pemulihan kunci publik, yang telah memberikan fleksibilitas dengan mengorbankan keamanan untuk tanda tangan adaptor atau multisignature.
Meskipun ada perubahan-perubahan ini, peretasan tetap berlanjut, begitu juga dengan keyakinan di kalangan para pengagum yang entah bagaimana, beberapa kasus ekstrim mungkin ditemukan yang akan memungkinkan dukungan perjanjian dalam Bitcoin. Pada awal 2020-an, dua perkembangan tertentu mencuat. Salah satunya adalah penemuan saya sendiri bahwa perjanjian berbasis tanda tangan tidak mati dengan pemulihan kunci publik, dan terutama, jika kita memiliki bahkan satu opcode yang dinonaktifkan kembali -- OP_CAT -- ini sudah cukup untuk konstruksi perjanjian yang cukup efisien. Yang lainnya adalah BitVM, cara baru untuk melakukan komputasi besar di dalam beberapa transaksi, yang menginspirasi sejumlah besar penelitian tentang komputasi dasar dalam satu transaksi.
Kedua perkembangan ini menginspirasi banyak aktivitas dan kegembiraan seputar perjanjian, tetapi juga mengkristalkan pemikiran kami tentang keterbatasan mendasar dari . Terutama, tampaknya perjanjian mungkin tidak mungkin dilakukan tanpa opcode baru, karena data transaksi hanya dipasok melalui tanda tangan 64 byte dan kunci publik 32 byte, sedangkan opcode yang mendukung BitVM hanya dapat bekerja dengan objek 4 byte. Pembagian ini disebut "Small " dan "Big ", dan menemukan jembatan antara keduanya menjadi sinonim (setidaknya menurut saya) dengan menemukan konstruksi perjanjian.
Enkripsi Fungsional dan PIPEs
Juga diamati bahwa, dengan sedikit matematika bulan, mungkin memungkinkan untuk melakukan perjanjian sepenuhnya dalam tanda tangan itu sendiri, tanpa pernah meninggalkan Big . Ide ini dirumuskan oleh Jeremy Rubin dalam makalahnya FE'd Up Covenants, yang menjelaskan cara mengimplementasikan perjanjian menggunakan primitif kripto hipotetis yang disebut enkripsi fungsional. Beberapa bulan kemudian, Misha Komorov mengusulkan skema khusus yang disebut PIPEs yang tampaknya membuat ide hipotetis ini menjadi kenyataan.
Ini adalah perkembangan yang menarik, meskipun memiliki dua keterbatasan utama: yang pertama adalah melibatkan setup yang terpercaya, yang berarti orang yang membuat perjanjian dapat mengabaikan aturannya. (Ini baik untuk sesuatu seperti vaults, di mana pemilik koin dapat dipercaya untuk tidak merusak keamanannya sendiri; tetapi tidak baik untuk sesuatu seperti kolam pembayaran di mana koin-koin dalam perjanjian tidak dimiliki oleh pencipta perjanjian.) Keterbatasan lainnya adalah melibatkan kriptografi canggih dengan sifat keamanan yang tidak jelas. Keterbatasan terakhir ini akan hilang dengan lebih banyak penelitian, tetapi setup yang terpercaya adalah hal yang melekat pada pendekatan fungsional-enkripsi.
Collider
Ikhtisar ini membawa kita ke situasi saat ini: kami ingin menemukan cara untuk mengimplementasikan perjanjian menggunakan bentuk Bitcoin yang ada, dan kami percaya bahwa cara untuk melakukannya adalah dengan menemukan semacam jembatan antara "Big" dari tanda tangan transaksi dan "Small" dari komputasi sembarang. Tampaknya tidak ada opcode yang dapat langsung membentuk jembatan ini (lihat Lampiran A di makalah kami untuk klasifikasi semua opcode dalam hal ukuran input dan output mereka). Sebuah jembatan, jika ada, akan menjadi semacam konstruksi yang mengambil satu objek besar dan menunjukkan bahwa itu persis sama dengan penggabungan beberapa objek kecil. Tampaknya, berdasarkan klasifikasi opcode kami, ini tidak mungkin.
Namun, dalam kriptografi kita sering melemahkan konsep seperti "sama persis", dan menggunakan konsep seperti "tidak dapat dibedakan secara komputasi" atau "tidak dapat dibedakan secara statistik", dan dengan demikian menghindari hasil yang mustahil. Mungkin, dengan menggunakan konstruksi kriptografi bawaan Big -- hash dan tanda tangan kurva eliptik -- dan dengan memperlihatkannya menggunakan konstruksi BitVM di Small , kita bisa menemukan cara untuk menampilkan bahwa objek besar "tidak dapat dibedakan secara komputasi" dari serangkaian objek kecil? Dengan Collider, itulah yang kami lakukan.
Apa artinya ini? Nah, ingatlah bounty tumbukan fungsi hash yang kami sebutkan sebelumnya. Dasar dari bounty ini adalah bahwa siapa pun yang dapat "bertumbukan" fungsi hash, dengan memberikan dua input yang memiliki keluaran hash yang sama, dapat membuktikan dalam Big bahwa mereka melakukannya, dan dengan demikian mengklaim bounty. Karena ruang input dari fungsi hash jauh lebih besar (semua bytestring dengan ukuran hingga 520 byte) dibandingkan dengan ruang keluaran (bytestring dengan ukuran tepat 32 byte), secara matematis harus ada banyak sekali tumbukan seperti itu. Namun, kecuali SHA1, belum ada yang menemukan cara yang lebih cepat untuk menemukan tumbukan ini selain dengan hanya memanggil fungsi hash berulang-ulang dan melihat apakah hasilnya cocok dengan percobaan sebelumnya.
Ini berarti bahwa, rata-rata, untuk fungsi hash 160-bit seperti SHA1 atau RIPEMD160, seorang pengguna akan perlu melakukan setidaknya 2^80 pekerjaan, atau sejuta juta juta juta iterasi, untuk menemukan tabrakan. (Dalam kasus SHA1, ada pintasan jika pengguna dapat menggunakan masukan dari bentuk tertentu; tetapi konstruksi kami melarang ini sehingga untuk tujuan kami kami dapat mengabaikan serangan ini.) Ini mengasumsikan bahwa pengguna memiliki jumlah memori yang efektif tak terbatas untuk bekerja; dengan asumsi yang lebih realistis, kita perlu menambahkan faktor lain sekitar seratus atau lebih.
Jika kita membayangkan bahwa SHA1 dan RIPEMD160 dapat dihitung dengan efisien seperti yang dilakukan oleh ASIC Bitcoin dalam menghitung SHA256, maka biaya perhitungan tersebut akan sekitar sama dengan 200 blok, atau sekitar 625 BTC (46 juta dolar). Ini adalah jumlah uang yang besar, tetapi banyak orang memiliki akses ke jumlah tersebut, sehingga hal ini memungkinkan.
Untuk menemukan tabrakan triple, atau tiga input yang menghasilkan hal yang sama, akan membutuhkan sekitar 2^110 pekerjaan, bahkan dengan asumsi yang sangat murah hati tentang akses ke memori. Untuk mendapatkan angka ini, kita perlu menambahkan faktor lain sebesar 16 juta ke biaya kita -- membawa total kita menjadi lebih dari 700 triliun dolar. Ini juga banyak uang, dan yang mana tidak ada yang memiliki akses ke hari ini.
Inti dari konstruksi kami adalah sebagai berikut: untuk membuktikan bahwa serangkaian objek kecil setara dengan satu objek besar, pertama-tama kami menemukan tabrakan hash antara objek target kami (yang kami anggap dapat diacak ulang dengan cara tertentu, atau kita akan melakukan "pencarian preimage kedua" daripada pencarian tabrakan, yang akan jauh lebih sulit) dan objek pengujian kesetaraan. Objek pengujian kesetaraan ini dibangun sedemikian rupa sehingga mereka dapat dengan mudah dimanipulasi baik dalam Big dan Small.
Konstruksi kami kemudian memeriksa, dalam Bitcoin, bahwa objek besar kami bertabrakan dengan pengujian kesetaraan kami (menggunakan metode yang sama persis seperti dalam bounty hash-collision) dan bahwa rangkaian objek kecil kami bertabrakan dengan pengujian kesetaraan (menggunakan konstruksi kompleks sebagian dicuri dari proyek BitVM, dan dijelaskan secara detail dalam makalah). Jika pemeriksaan ini berhasil, maka baik objek kecil maupun besar kami adalah sama, atau pengguna menemukan triple-collision: dua objek yang berbeda yang keduanya bertabrakan dengan pengujian. Berdasarkan argumen kami di atas, ini tidak mungkin.
Kesimpulan
Membangun Jembatan Kecil dan Besar adalah bagian tersulit dari konstruksi perjanjian kami. Untuk beralih dari jembatan ini ke perjanjian sebenarnya, ada beberapa langkah lagi, yang relatif mudah dilakukan. Khususnya, perjanjian pertama-tama meminta pengguna untuk menandatangani transaksi menggunakan "kunci generator" khusus, yang dapat kita verifikasi menggunakan opcode OP_CHECKSIG. Dengan menggunakan jembatan, kita memecah tanda tangan ini menjadi potongan 4 byte. Kemudian kita memverifikasi bahwa nonce-nya juga sama dengan kunci generator, yang mudah dilakukan setelah tanda tangan telah dipecah. Akhirnya, kita menggunakan teknik dari trik Schnorr untuk mengekstraksi data transaksi dari tanda tangan, yang kemudian dapat dibatasi sesuai keinginan perjanjian.
Ada beberapa hal lain yang dapat kita lakukan: Lampiran C menggambarkan konstruksi tanda tangan cincin yang akan memungkinkan koin ditandatangani oleh salah satu dari sekumpulan kunci publik, tanpa mengungkapkan kunci mana yang digunakan. Dalam hal ini, kita menggunakan bridge untuk memecah kunci publik, bukan tanda tangan. Melakukannya memberikan peningkatan efisiensi yang signifikan dibandingkan dengan konstruksi perjanjian, karena alasan teknis yang terkait dengan Taproot dan dijelaskan secara detail dalam paper.
Sebuah aplikasi akhir yang ingin saya menarik perhatian, dibahas secara singkat di Bagian 7.2 dari makalah ini, adalah bahwa kita dapat menggunakan konstruksi perjanjian kami untuk menarik hash transaksi keluar dari tanda tangan Schnorr, dan kemudian hanya menandatangani ulang hash menggunakan tanda tangan Lamport.
Mengapa kita akan melakukan ini? Seperti yang diperdebatkan dalam tautan di atas, menandatangani tanda tangan Lamport dengan cara ini membuatnya menjadi tanda tangan yang aman dari quantum pada data transaksi; jika konstruksi ini adalah satu-satunya cara untuk menandatangani untuk beberapa koin, mereka akan kebal dari pencurian oleh komputer kuantum.
Tentu saja, karena pembangunan kami memerlukan puluhan juta dolar untuk digunakan, tidak ada yang akan membuat pembangunan ini menjadi satu-satunya cara untuk menandatangani koin mereka. Tetapi tidak ada yang menghentikan seseorang untuk menambahkan pembangunan ini ke koin mereka, selain dari metode pengeluaran mereka yang tidak aman dalam hal kuantum.
Kemudian, jika kita bangun esok hari dan menemukan bahwa komputer kuantum murah telah ada yang mampu membobol tanda tangan Bitcoin, kita mungkin akan mengusulkan soft-fork darurat yang menonaktifkan semua tanda tangan kurva eliptik, termasuk baik pengeluaran kunci Taproot maupun opcode OP_CHECKSIG. Ini akan efektif membekukan semua koin orang; tetapi jika pilihan lainnya adalah bahwa semua koin orang bisa dengan bebas dicuri, mungkin tidak akan ada perbedaan apa pun. Jika soft-fork ini yang menonaktifkan tanda tangan memungkinkan opcode OP_CHECKSIG saat dipanggil dengan kunci generator (tanda tangan seperti ini tidak memberikan keamanan apa pun, dan hanya berguna sebagai blok bangunan untuk konstruksi kompleks seperti yang kita miliki), maka pengguna konstruksi tanda tangan Lamport kita dapat terus mengeluarkan koin mereka dengan bebas, tanpa takut disita atau dicuri.
Tentu saja, mereka perlu mengeluarkan puluhan juta dolar untuk melakukannya, tetapi ini jauh lebih baik daripada "mustahil"! Dan kami berharap dan berharap melihat biaya ini turun drastis, karena orang-orang membangun berdasarkan penelitian kami.
Ini adalah kiriman tamu oleh Andrew Poelstra. Pendapat yang disampaikan sepenuhnya milik mereka sendiri dan tidak selalu mencerminkan pendapat BTC Inc atau Bitcoin Magazine.
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Collider_: Sebuah Perjanjian Bitcoin senilai $50 Juta Tanpa Kode Operasi Baru
Sementara tahun lalu atau dua telah melihat sejumlah proposal untuk perpanjangan yang mengusulkan perjanjian untuk Bitcoin, selalu ada kecurigaan di kalangan para ahli bahwa perjanjian mungkin memungkinkan tanpa adanya perpanjangan. Bukti untuk ini datang dalam dua bentuk: repertoar komputasi yang sebelumnya dianggap tidak mungkin berkembang (yang mencapai puncaknya dalam proyek BitVM untuk mengimplementasikan setiap opcode RISC-V), dan serangkaian "hampir-hampir" dimana pengembang Bitcoin telah menemukan cara bahwa perjanjian mungkin telah memungkinkan, jika bukan karena beberapa kejadian sejarah yang gelap dari .
Ethan Heilman, Avihu Levy, Victor Kobolov, dan saya telah mengembangkan sebuah skema yang membuktikan bahwa kecurigaan ini berdasar. Skema kita, Collider, memungkinkan perjanjian di Bitcoin saat ini, dengan asumsi kriptografi yang cukup masuk akal dan biaya sekitar 50 juta dolar per transaksi (ditambah dengan beberapa riset dan pengembangan perangkat keras).
Meskipun biaya yang fantastis untuk menggunakan Collider, pengaturannya sangat murah, dan melakukannya (bersama mekanisme pengeluaran biasa, menggunakan Taproot untuk memisahkan keduanya) mungkin saja menyelamatkan koin Anda jika komputer kuantum muncul tiba-tiba dan meledakkan semuanya.
Tak diragukan lagi banyak pembaca, setelah membaca klaim-klaim ini, akan mengangkat satu alis ke langit. Ketika Anda selesai membaca artikel ini, alis yang lain akan sama tingginya.
Perjanjian
Konteks dari diskusi ini, bagi mereka yang tidak familiar, adalah bahwa Bitcoin memiliki bahasa pemrograman bawaan, yang disebut Bitcoin, yang digunakan untuk mengotorisasi pengeluaran koin. Pada awalnya, Bitcoin mengandung seperangkat lengkap kode operasi aritmatika yang dapat digunakan untuk menerapkan perhitungan sembarang. Tetapi pada musim panas 2010, Satoshi menonaktifkan banyak dari ini dalam pesanan untuk menghentikan serangkaian bug serius. (Kembali ke versi sebelum 2010 dari Bitcoin adalah tujuan dari Proyek Restorasi Hebat; OP_CAT adalah proposal yang kurang ambisius dengan arah yang sama.) Ide kovenan - transaksi yang menggunakan Bitcoin untuk mengontrol jumlah dan tujuan koin mereka - tidak muncul dalam beberapa tahun lagi, dan kesadaran bahwa kode operasi ini sudah cukup untuk menerapkan kovenan baru muncul bahkan lebih lama. Pada saat itu, komunitas sudah terlalu besar dan berhati-hati untuk sekadar "mengaktifkan kembali" kode operasi lama dengan cara yang sama seperti saat mereka dinonaktifkan.
Covenants adalah konstruksi hipotetis yang akan memungkinkan pengguna mengontrol tidak hanya kondisi di mana koin dihabiskan, tetapi juga tujuan mereka. Ini adalah dasar untuk banyak konstruksi yang akan ada di Bitcoin, mulai dari brankas dan dompet terbatas tarif, hingga mekanisme pasar biaya baru seperti kolam pembayaran, hingga konstruksi yang kurang menyenangkan seperti keuangan terdistribusi dan MEV. Jutaan kata telah dihabiskan untuk mendebatkan keinginan akan covenants dan apa yang akan mereka lakukan terhadap sifat Bitcoin.
Dalam artikel ini, saya akan menghindari perdebatan ini, dan hanya berargumen bahwa perjanjian sudah mungkin dilakukan pada Bitcoin; bahwa kita pada akhirnya akan menemukan bagaimana hal-hal itu mungkin dilakukan (tanpa biaya komputasi yang besar atau asumsi kriptografis yang meragukan); dan bahwa perdebatan kita tentang perluasan baru untuk Bitcoin tidak boleh dianggap sebagai garis pemisah antara masa depan Bitcoin tanpa perjanjian atau masa depan Bitcoin dengan perjanjian.
Sejarah
Selama bertahun-tahun, sebuah tradisi berkembang untuk menemukan cara-cara kreatif untuk melakukan hal-hal yang tidak sepele meskipun dengan sumber daya terbatas. Jaringan Lightning adalah salah satu contoh dari hal ini, begitu juga dengan gagasan-gagasan yang kurang dikenal seperti pembayaran probabilitas atau hadiah tabrakan untuk fungsi hash. Kasus-kasus tepi yang tidak terlalu dikenal, seperti bug SIGHASH_SINGLE atau penggunaan pemulihan kunci publik untuk mendapatkan "hash transaksi" dalam interpreter, diperhatikan dan dieksplorasi, tetapi tidak ada yang berhasil menemukan cara untuk membuat mereka berguna. Sementara itu, Bitcoin sendiri berkembang menjadi lebih terdefinisi dengan lebih baik, menutup banyak pintu-pintu ini. Misalnya, Segwit menghilangkan bug SIGHASH_SINGLE dan secara eksplisit memisahkan data program dari data saksi; Taproot menghilangkan pemulihan kunci publik, yang telah memberikan fleksibilitas dengan mengorbankan keamanan untuk tanda tangan adaptor atau multisignature.
Meskipun ada perubahan-perubahan ini, peretasan tetap berlanjut, begitu juga dengan keyakinan di kalangan para pengagum yang entah bagaimana, beberapa kasus ekstrim mungkin ditemukan yang akan memungkinkan dukungan perjanjian dalam Bitcoin. Pada awal 2020-an, dua perkembangan tertentu mencuat. Salah satunya adalah penemuan saya sendiri bahwa perjanjian berbasis tanda tangan tidak mati dengan pemulihan kunci publik, dan terutama, jika kita memiliki bahkan satu opcode yang dinonaktifkan kembali -- OP_CAT -- ini sudah cukup untuk konstruksi perjanjian yang cukup efisien. Yang lainnya adalah BitVM, cara baru untuk melakukan komputasi besar di dalam beberapa transaksi, yang menginspirasi sejumlah besar penelitian tentang komputasi dasar dalam satu transaksi.
Kedua perkembangan ini menginspirasi banyak aktivitas dan kegembiraan seputar perjanjian, tetapi juga mengkristalkan pemikiran kami tentang keterbatasan mendasar dari . Terutama, tampaknya perjanjian mungkin tidak mungkin dilakukan tanpa opcode baru, karena data transaksi hanya dipasok melalui tanda tangan 64 byte dan kunci publik 32 byte, sedangkan opcode yang mendukung BitVM hanya dapat bekerja dengan objek 4 byte. Pembagian ini disebut "Small " dan "Big ", dan menemukan jembatan antara keduanya menjadi sinonim (setidaknya menurut saya) dengan menemukan konstruksi perjanjian.
Enkripsi Fungsional dan PIPEs
Juga diamati bahwa, dengan sedikit matematika bulan, mungkin memungkinkan untuk melakukan perjanjian sepenuhnya dalam tanda tangan itu sendiri, tanpa pernah meninggalkan Big . Ide ini dirumuskan oleh Jeremy Rubin dalam makalahnya FE'd Up Covenants, yang menjelaskan cara mengimplementasikan perjanjian menggunakan primitif kripto hipotetis yang disebut enkripsi fungsional. Beberapa bulan kemudian, Misha Komorov mengusulkan skema khusus yang disebut PIPEs yang tampaknya membuat ide hipotetis ini menjadi kenyataan.
Ini adalah perkembangan yang menarik, meskipun memiliki dua keterbatasan utama: yang pertama adalah melibatkan setup yang terpercaya, yang berarti orang yang membuat perjanjian dapat mengabaikan aturannya. (Ini baik untuk sesuatu seperti vaults, di mana pemilik koin dapat dipercaya untuk tidak merusak keamanannya sendiri; tetapi tidak baik untuk sesuatu seperti kolam pembayaran di mana koin-koin dalam perjanjian tidak dimiliki oleh pencipta perjanjian.) Keterbatasan lainnya adalah melibatkan kriptografi canggih dengan sifat keamanan yang tidak jelas. Keterbatasan terakhir ini akan hilang dengan lebih banyak penelitian, tetapi setup yang terpercaya adalah hal yang melekat pada pendekatan fungsional-enkripsi.
Collider
Ikhtisar ini membawa kita ke situasi saat ini: kami ingin menemukan cara untuk mengimplementasikan perjanjian menggunakan bentuk Bitcoin yang ada, dan kami percaya bahwa cara untuk melakukannya adalah dengan menemukan semacam jembatan antara "Big" dari tanda tangan transaksi dan "Small" dari komputasi sembarang. Tampaknya tidak ada opcode yang dapat langsung membentuk jembatan ini (lihat Lampiran A di makalah kami untuk klasifikasi semua opcode dalam hal ukuran input dan output mereka). Sebuah jembatan, jika ada, akan menjadi semacam konstruksi yang mengambil satu objek besar dan menunjukkan bahwa itu persis sama dengan penggabungan beberapa objek kecil. Tampaknya, berdasarkan klasifikasi opcode kami, ini tidak mungkin.
Namun, dalam kriptografi kita sering melemahkan konsep seperti "sama persis", dan menggunakan konsep seperti "tidak dapat dibedakan secara komputasi" atau "tidak dapat dibedakan secara statistik", dan dengan demikian menghindari hasil yang mustahil. Mungkin, dengan menggunakan konstruksi kriptografi bawaan Big -- hash dan tanda tangan kurva eliptik -- dan dengan memperlihatkannya menggunakan konstruksi BitVM di Small , kita bisa menemukan cara untuk menampilkan bahwa objek besar "tidak dapat dibedakan secara komputasi" dari serangkaian objek kecil? Dengan Collider, itulah yang kami lakukan.
Apa artinya ini? Nah, ingatlah bounty tumbukan fungsi hash yang kami sebutkan sebelumnya. Dasar dari bounty ini adalah bahwa siapa pun yang dapat "bertumbukan" fungsi hash, dengan memberikan dua input yang memiliki keluaran hash yang sama, dapat membuktikan dalam Big bahwa mereka melakukannya, dan dengan demikian mengklaim bounty. Karena ruang input dari fungsi hash jauh lebih besar (semua bytestring dengan ukuran hingga 520 byte) dibandingkan dengan ruang keluaran (bytestring dengan ukuran tepat 32 byte), secara matematis harus ada banyak sekali tumbukan seperti itu. Namun, kecuali SHA1, belum ada yang menemukan cara yang lebih cepat untuk menemukan tumbukan ini selain dengan hanya memanggil fungsi hash berulang-ulang dan melihat apakah hasilnya cocok dengan percobaan sebelumnya.
Ini berarti bahwa, rata-rata, untuk fungsi hash 160-bit seperti SHA1 atau RIPEMD160, seorang pengguna akan perlu melakukan setidaknya 2^80 pekerjaan, atau sejuta juta juta juta iterasi, untuk menemukan tabrakan. (Dalam kasus SHA1, ada pintasan jika pengguna dapat menggunakan masukan dari bentuk tertentu; tetapi konstruksi kami melarang ini sehingga untuk tujuan kami kami dapat mengabaikan serangan ini.) Ini mengasumsikan bahwa pengguna memiliki jumlah memori yang efektif tak terbatas untuk bekerja; dengan asumsi yang lebih realistis, kita perlu menambahkan faktor lain sekitar seratus atau lebih.
Jika kita membayangkan bahwa SHA1 dan RIPEMD160 dapat dihitung dengan efisien seperti yang dilakukan oleh ASIC Bitcoin dalam menghitung SHA256, maka biaya perhitungan tersebut akan sekitar sama dengan 200 blok, atau sekitar 625 BTC (46 juta dolar). Ini adalah jumlah uang yang besar, tetapi banyak orang memiliki akses ke jumlah tersebut, sehingga hal ini memungkinkan.
Untuk menemukan tabrakan triple, atau tiga input yang menghasilkan hal yang sama, akan membutuhkan sekitar 2^110 pekerjaan, bahkan dengan asumsi yang sangat murah hati tentang akses ke memori. Untuk mendapatkan angka ini, kita perlu menambahkan faktor lain sebesar 16 juta ke biaya kita -- membawa total kita menjadi lebih dari 700 triliun dolar. Ini juga banyak uang, dan yang mana tidak ada yang memiliki akses ke hari ini.
Inti dari konstruksi kami adalah sebagai berikut: untuk membuktikan bahwa serangkaian objek kecil setara dengan satu objek besar, pertama-tama kami menemukan tabrakan hash antara objek target kami (yang kami anggap dapat diacak ulang dengan cara tertentu, atau kita akan melakukan "pencarian preimage kedua" daripada pencarian tabrakan, yang akan jauh lebih sulit) dan objek pengujian kesetaraan. Objek pengujian kesetaraan ini dibangun sedemikian rupa sehingga mereka dapat dengan mudah dimanipulasi baik dalam Big dan Small.
Konstruksi kami kemudian memeriksa, dalam Bitcoin, bahwa objek besar kami bertabrakan dengan pengujian kesetaraan kami (menggunakan metode yang sama persis seperti dalam bounty hash-collision) dan bahwa rangkaian objek kecil kami bertabrakan dengan pengujian kesetaraan (menggunakan konstruksi kompleks sebagian dicuri dari proyek BitVM, dan dijelaskan secara detail dalam makalah). Jika pemeriksaan ini berhasil, maka baik objek kecil maupun besar kami adalah sama, atau pengguna menemukan triple-collision: dua objek yang berbeda yang keduanya bertabrakan dengan pengujian. Berdasarkan argumen kami di atas, ini tidak mungkin.
Kesimpulan
Membangun Jembatan Kecil dan Besar adalah bagian tersulit dari konstruksi perjanjian kami. Untuk beralih dari jembatan ini ke perjanjian sebenarnya, ada beberapa langkah lagi, yang relatif mudah dilakukan. Khususnya, perjanjian pertama-tama meminta pengguna untuk menandatangani transaksi menggunakan "kunci generator" khusus, yang dapat kita verifikasi menggunakan opcode OP_CHECKSIG. Dengan menggunakan jembatan, kita memecah tanda tangan ini menjadi potongan 4 byte. Kemudian kita memverifikasi bahwa nonce-nya juga sama dengan kunci generator, yang mudah dilakukan setelah tanda tangan telah dipecah. Akhirnya, kita menggunakan teknik dari trik Schnorr untuk mengekstraksi data transaksi dari tanda tangan, yang kemudian dapat dibatasi sesuai keinginan perjanjian.
Ada beberapa hal lain yang dapat kita lakukan: Lampiran C menggambarkan konstruksi tanda tangan cincin yang akan memungkinkan koin ditandatangani oleh salah satu dari sekumpulan kunci publik, tanpa mengungkapkan kunci mana yang digunakan. Dalam hal ini, kita menggunakan bridge untuk memecah kunci publik, bukan tanda tangan. Melakukannya memberikan peningkatan efisiensi yang signifikan dibandingkan dengan konstruksi perjanjian, karena alasan teknis yang terkait dengan Taproot dan dijelaskan secara detail dalam paper.
Sebuah aplikasi akhir yang ingin saya menarik perhatian, dibahas secara singkat di Bagian 7.2 dari makalah ini, adalah bahwa kita dapat menggunakan konstruksi perjanjian kami untuk menarik hash transaksi keluar dari tanda tangan Schnorr, dan kemudian hanya menandatangani ulang hash menggunakan tanda tangan Lamport.
Mengapa kita akan melakukan ini? Seperti yang diperdebatkan dalam tautan di atas, menandatangani tanda tangan Lamport dengan cara ini membuatnya menjadi tanda tangan yang aman dari quantum pada data transaksi; jika konstruksi ini adalah satu-satunya cara untuk menandatangani untuk beberapa koin, mereka akan kebal dari pencurian oleh komputer kuantum.
Tentu saja, karena pembangunan kami memerlukan puluhan juta dolar untuk digunakan, tidak ada yang akan membuat pembangunan ini menjadi satu-satunya cara untuk menandatangani koin mereka. Tetapi tidak ada yang menghentikan seseorang untuk menambahkan pembangunan ini ke koin mereka, selain dari metode pengeluaran mereka yang tidak aman dalam hal kuantum.
Kemudian, jika kita bangun esok hari dan menemukan bahwa komputer kuantum murah telah ada yang mampu membobol tanda tangan Bitcoin, kita mungkin akan mengusulkan soft-fork darurat yang menonaktifkan semua tanda tangan kurva eliptik, termasuk baik pengeluaran kunci Taproot maupun opcode OP_CHECKSIG. Ini akan efektif membekukan semua koin orang; tetapi jika pilihan lainnya adalah bahwa semua koin orang bisa dengan bebas dicuri, mungkin tidak akan ada perbedaan apa pun. Jika soft-fork ini yang menonaktifkan tanda tangan memungkinkan opcode OP_CHECKSIG saat dipanggil dengan kunci generator (tanda tangan seperti ini tidak memberikan keamanan apa pun, dan hanya berguna sebagai blok bangunan untuk konstruksi kompleks seperti yang kita miliki), maka pengguna konstruksi tanda tangan Lamport kita dapat terus mengeluarkan koin mereka dengan bebas, tanpa takut disita atau dicuri.
Tentu saja, mereka perlu mengeluarkan puluhan juta dolar untuk melakukannya, tetapi ini jauh lebih baik daripada "mustahil"! Dan kami berharap dan berharap melihat biaya ini turun drastis, karena orang-orang membangun berdasarkan penelitian kami.
Ini adalah kiriman tamu oleh Andrew Poelstra. Pendapat yang disampaikan sepenuhnya milik mereka sendiri dan tidak selalu mencerminkan pendapat BTC Inc atau Bitcoin Magazine.